home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1199 / 1662 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.5 KB
  1. Subject: Re: MiNT 1.10 re-sync
  2. Date: Fri, 17 Jun 94 23:13:50 CDT
  3. From: Juergen Lock <nox@jelal.north.de>
  4. In-Reply-To: <21452.9406170657@elvis.earth.ox.ac.uk>; from "Stephen Usher" at Jun 17, 94 7:57 am
  5. Message-Id: <9406172113.AA00535@jelal.north.de>
  6.  
  7. Stephen Usher writes:
  8.  
  9. > >Michael Hohmuth writes:
  10. > >
  11. > >> > 6. and now the sticky text/fragmentation megapatch...  does a few things:
  12. > >> 
  13. > >> > . execv..() frees the old process memory before allocating the new ones,
  14. > >> > and so no longer leaves holes in your memory map.  this took a few
  15. > >> > ugly hacks but i think its worth it :)  the only visible change should
  16. > >> > be when exec'ing a damaged binary the process gets killed, fixing that
  17. > >> > would require reading executables twice.
  18. > >> 
  19. > >> Well, that's fine with me, but I don't know whether this "non-posixish"
  20. > >> behaviour is tolerable by all others?  I guess so... as it effectively
  21. > >> makes "damaged executable" equivalent to "executable crashed immediately
  22. > >> after it has been run".
  23. > 
  24. > Hmm.. I think this is bad as many programs have code after an exec which
  25. > takes alternate action if the exec fails.
  26.  
  27.  well that still works for the usual cases (bad magic, ENOMEM, ENOENT...)
  28. the kill should only happen when the executable header looked ok and the
  29. error is somewhere later in the file.  i.e. you need a broken linker,
  30. overwritten blocks, or some filesystem error for this to happen...
  31.  
  32. >  The alternative, of course, is to
  33. > copy the original text elsewhere before loading the new program if the new
  34. > program's text is smaller or the same size as the original program. If the
  35. > exec fails then it can be copied back and the process resumed.
  36.  
  37.  thats another idea but is it worth it? :)
  38.  
  39. >  If the new
  40. > process being exec()ed is larger than the original program (and the memory
  41. > above the current program isn't free) then exec()ing as we do now would be
  42. > no problem.
  43.  
  44.  hmm but you'd still get a hole?
  45. > 
  46. > The only sure way to stop memory fragmentation is to start using paged
  47. > memory management. This, of course, can only be done on the 68030 and above.
  48.  
  49.  yup
  50. > 
  51. > > or whats on systems that demand-page text instead of loading it all at
  52. > >once...  do they always check the entire file before?
  53. > >> 
  54. > >> Opinions?
  55. > >
  56. > > should there be some flag to turn it off?  in mint.cnf?
  57.  
  58.  cheers
  59.     Juergen
  60. -- 
  61. J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
  62.                                 ...ohne Gewehr
  63. PGP public key fingerprint =  8A 18 58 54 03 7B FC 12  1F 8B 63 C7 19 27 CF DA 
  64.